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ABSTRACT 


This thesis is intended to provide a Navy Logistician with an overview of 
computer modeling and simulation uses and management within the Department of 
the Navy. This thesis research indicates a large demand for models and simulations 
with joint applicability. It also indicates the need for the Navy to examine modeling 
and simulation management and organization to ensure economic and effective 
utilization. With decreasing Department of Defense budgets, the efficient 
management of this critical resource and capability is extremely important. The 
information contained in this thesis will be of value for a Navy logistician in 
providing knowledge about a few models and simulations and the trend towards 
joint applicability. 
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I. INTRODUCTION 


A. BACKGROUND 

Simulation is one of the most frequently used system 
analysis methods. There are a number of reasons for this. 

First, simulation can be used to analyze models of arbitrary 
complexity. The complexity of the model is limited only by 
the ability of the modeler and the methodology to represent 
the system’s complexity, and the computer’s capacity to load 
and run the simulation program. The investigator’s primary 
interest might be to experiment with the system model in 
order to find the design that maximizes one or more 
performance measures, or simply to study the behavior of 
the system. Experimenting with the real system is often out 
of the question because of the cost to implement system 
changes, or the potential danger that could result from some 
policies being tested. Often the modeling effort is useful in 
itself. The process of model development requires the 
system to be studied and understood well. This study 
frequently uncovers problems diat were unknown or not 
understood before. Relative to other methodologies, 
simulation can carry more credibility with decision makers. 

For example, an animation, which is a visual representation 
of the model, can be used to demonstrate that the model 
actually approximates system performance. Thus, a 
simulation feels more “real” than other methods for system 
analysis. (Alexopoulos etal., 1995) 

Computer modeling and simulation continues to take on increased use and focus in 
the Department of Defense (DoD). But now with reducing force levels and increasingly 
tight fiscal constraints the payoff of computer modeling and simulation is being seriously 
scrutinized. On June 1991 the Defense Modeling and Simulation Office (DMSO) was 
established by the Undersecretary of Defense for Acquisition. In addition to the 
promulgation of modeling and simulation policy, DMSO was to promote cooperation 
among DoD components in order to maximize efficiency and effectiveness. (MSIS, 1995, 
web) 


However, it appears that a degree of dissatisfaction with the management of 
computer modeling and simulation exists within the DoD. Specifically, Pentagon officials 
cut funding for the DMSO about $ 11 million to a level of about $52 million. Funds could 
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have been cut to as low as $40 million. While no programs were canceled “in-depth 
reviews of all priorities are continuing”. A defense source stated, “we need to go back and 
look at all simulation priorities.” (Holzer, 1996, p. 16) 

While the DoD is cutting funding to the main computer modeling and simulation 
office, the individual military departments 2 ire preparing for possible congressional budget 
attacks. Army Chief of Staff Gen. Dennis Reimer has initiated a complete internal review of 
modeling and simulation funding. The Army allocates almost two percent of its 
discretionary funding to computer modeling and simulation. This computes to about $710 
million for fiscal year 1997. “However simulation costs are rising and the Army is still 
asking for the same levels of OPTEMPO funding today as we have in the past.” Gen. 
Reimer believes that Congress will find fault with the Army’s investment efforts and that 
justification to Congress will be difficult. This will result more than likely in a reduction in 
funding. (Sherman, 1995) 

Before we go any further, we must define a model and a simulation. A model is a 
representation of a system or process. A simulation is the implementation of a model over 
time. For the logistician, the most widely used model among all the military services is the 
level-of-repair analysis (LORA). With more emphasis on joint operations and joint 
acquisitions programs, such as the Joint Strike Fighter Program (JSPO, it is important that a 
Navy logistician understand the level of repair analysis models of our sister services. 

Each service has its own variation of LORA. The Army now uses the 
Computerized Optimization Model for Predicting and Analyzing Support Structures 
(COMPASS). This model replaced the optimum supply and maintenance model 
(OSAMM). The Navy uses the Level Of Repair Analysis (LORA) model and the Air Force 
uses the Network Repair Level Analysis (NRLA) model. As a Navy logistician it is 
important to understand the similarities and differences of these models. 
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B. FOCUS OF THESIS 


In this thesis, we will fcxjus on computer modeling and simulation uses within the 
DoD. This is a highly complex problem that is gaining increased budgetary focus. We will 
concentrate on some uses of computer modeling and simulation in the DoD. We will study 
DMSO and also an overview of the modeling and simulation structure of the Navy. Then 
we will look at other Navy computer modeling and simulation logistics issues, including a 
joint program within DoD and investigate whether the management organization can be 
applied to computer modeling and simulation. 

C. STRUCTURE OF THESIS 

Chapter II provides an overview of the variations of LORA used by each military 
service. Chapter III provides an overview of the Defense Modeling and Simulation Office 
(DMSO). It explores the organization, goals and future of the office. Additionally, this 
chapter provides and overview of the modeling and simulation management structure of the 
Navy. Chapter IV looks at a couple of issues within the Department of the Navy with 
regard to computer modeling and simulation. Chapter V highlights a few computer models 
in the area of joint logistics. Chapter VI provides the summary, conclusions and 
recommendations. 
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II. LEVEL OF REPAIR ANALYSIS (LORA) MODELS 

The purpose of this chapter is to examine LORA models being used by the different 

services. To perform the function of level of repair analysis, the Army, Air Force, and the 

Navy each uses a computer based, mathematical level of repair model. With decreasing 

defense budgets, it is highly likely that in a joint program, one would come into contact 

with a model from one of the other services. It is very important for military logisticians to 

be familiar with the similarities and differences of these math models. 

A. U.S. ARMY; COMPUTERIZED OPTIMIZATION MODEL FOR 
PREDICTING AND ANALYZING SUPPORT STRUCTURES (COMPASS) 

1. Background 

The development of COMPASS can be traced back to 1987. ‘The concept for 
developing COMPASS was originally conceived by a LORA subgroup at the LSA 
Technical Working Group (TWG) Meeting Number 6, 9-13 Feb 87. During this meeting, 
the subgroup determined models that were being used by the Army community for 
conducting LORA did not satisfy their needs.” (USAMC, 1994) Thus a new program was 
initiated to design and develop a new math model. COMPASS was this new math model, 
with an initial goal of completion of between 3 and 10 years. The mathematical equations 
used in Optimum Supply and Maintenance Model (OSAMM) were used as the “basis in the 
development of COMPASS.” (USAMC, 1994) COMPASS’s purpose was to conduct 
system-level LORA previously conducted by OSAMM and Logistics Analysis Model 
(LOGAM) and to operate on a personal computer (pc) vice a mainframe computer. Given 
the technological advances in computer’s, the result would be a program just as if not more 
powerful than its predecessors. 
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2. Model Overview 


a. COMPASS Products 

- “Repair level decision for each item under analysis.” 

- “Cost and allocation of manpower and support equipment required to 
repair the system.” 

- “Is it economical to develop test program sets (TPS)?” 

- “Is it economical to screen an item before it is evacuated to another 
maintenance echelon for repair?” 

- “Cost of initial and replenishment spares over the life of the system.” 

- “Overall costs associated with transportation, cataloging, training, 
technical manuals, etc.” 

- “Design for discard candidates.” 

- “ Source for development of the MAC and Source, Maintenance, and 
Recoverability (SMR) code.” (USAMC, 1994) 

b. Model Highlights 

- “Maintenance concept decisions are made within COMPASS by 
considering all maintenance and supply related functions concurrently.” 

- Supply algorithms used in COMPASS have been taken from the Selected 
Essential-Item Stockage Availability Method (SESAME) 

- “In order to determine the least cost maintenance alternative for each item, 
COMPASS formulates the problem in a linear programming form.” 

- If a user identifies an item in the input file, COMPASS will determine “the 
most economical location where the item should be removed and 
replaced, repaired or discarded.” 
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- The user identifies the manpower and support equipment required to repair 
the items. COMPASS determines the optimal location for the manpower 
and support equipment. 

- The user identifies lowest echelon where the repair equipment and 
repairperson is authorized and the lowest echelon where they are common. 
COMPASS computes the charges. 

-“Cost elements within COMPASS are a mixture of one time and annual 
recurring cost.” 

- COMPASS determines the most economical location of repair 
(government or contractor) 

- COMPASS considers basically 6 maintenance locations; 

- organizational (org) 

- direct suppxjit (ds) 

- general support (gs) 

- dep)ot 

- contractor 

- discard 

c. Model Outputs 

After the user has completed the building of the data file, there are three 
choices for execution. They are front-end analysis, optimizer, and evaluator. ‘The front- 
end analysis program should always be run before the optimizer or evaluator are run.” 
(USAMC, 1994) The front-end analysis program identifies all errors in the input file and 
can also provide the user with a copy of all the data contained in the file. The optimizer and 
the evaluator will not run if there are any errors present. The optimizer program determines 
“the optimum (least cost) maintenance concept for the weapon system.” (USAMC, 1994) 
The program will provide the optimum maintenance concept for each item the user listed in 
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the input file. It will also include the computation for life cycle and support cost for the 

maintenance concept that was selected. The evaluator program is “used to determine 

maintenance and support costs based on a user-defined maintenance concept.” (USAMC, 

1994) The user runs this program to conduct sensitivity analysis and to determine the effect 

on life cycle costs if a maintenance concept is changed or modified. 

B. U.S. AIR FORCE: NETWORK REPAIR LEVEL ANALYSIS MODEL 
(NRLA) 

1. Model Highlights 

- “NRLA is the preferred means of performing LORA.” It performs LORA for 
line replaceable units (LRU) and shop replaceable units (SRU) (ASC/ALTD, 1995) 

- The model does not include all life cycle cost elements. It only includes those that 
have a direct impact on repair level decisions. Therefore, it is not a 
comprehensive life cycle cost model. 

- The model chooses between three levels of repair: intermediate level repair, 
depot level repair, and discard -at-failure. 

- The model does not attempt to allocate support equipment costs to individual 
items. 

2. Model Assumptions 

- ‘The logistics system is composed of some number of operational locations 
(bases) and some number of centralized repair facilities (depots) supporting the 
bases.” (ASC/ALTD, 1995) The base has two repair facilities, flight line and base 
shop (intermediate). The model assumes all bases send repairables to the same 
depot. Therefore the model assumes only one depot. 

- “Intermediate level maintenance systems data (available work time per man, labor 
rate, and turnover rate) are assumed equal for all intermediate locations and all types 
of repair tasks.’’(ASC/ALTD, 1995) 
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- “Supply system data factors are assumed to be constant for all LRU’s and SRU’s 
being analyzed.” (ASC/ALTD, 1995) 

- “Only one set of technical data is purchased from the contractor.” (ASC/ALTD, 
1995) 

- “Scheduled maintenance actions are not specifically considered by the model.” 
(ASC/ALTD, 1995) 

- ‘The model explicitly evaluates each LRU failure mode for a repair level 
decision.” (ASC/ALTD, 1995) 

- The model only evaluates the principal SRU for repair level decisions. 

- The depot stock of SRU’s is computed to enable the depot to resupply the 
intermediate level when SRU’s are sent to depot for repair. 

3. Sensitivity Analysis 

The model can perform four types of sensitivity analysis. They are swept, extremes 
only, wholesale and pareto. In swept, the user selects a range (for example, MTBF of 200 
to 600 hours) and the program sweeps through the range one LRU or SRU at a time. When 
using extremes only, the sensitivity analysis is done only on the upper an lower extremes 
of the range chosen. In wholesale changes analysis, all changes for a given factor are made 
at the same time. This is usually used if the total system cost is of interest vice repair 
policy. In Pareto, only the highest cost or the lowest MTBF items are analyzed instead of 
analyzing all LRUs or SRUs. 

4. Model Outputs 

There are eleven types of output presented by the model. ‘They contain data input, 
intermediate results, supplementary information, the optimal solution, and sensitivity 
analysis.” (ASC/ALTD, 1995) All input record are printed in the output. The general 
information output report contains weapon system data, maintenance system data, supply 
system data, output options, and wholesale factors. Support Equipment and pareto change 


9 


factors are reported together. Repair Level Decision Details contain LRU, LRU failure 
mode, and SRU data. Support Equipment to LRU/SRU Relationships is also an output 
report. The user of the model can designate which output options he wants to receive. 
However, “the reports that are not optional are the Repair Level Decisions, Summary 
Statistics, Summary Sensitivity Analysis Results, and Detailed Sensitivity Analysis 
Results.” (ASC/ALTD, 1995) 

C. U.S. NAVY: LEVEL OF REPAIR ANALYSIS (LORA) 

1. Background 

LORA is used to ensure the optimum economic use of resources. Its purpose is to 
determine the least-cost feasible repair or discard decision with regard to corrective 
maintenance and to influence the design of the equipment toward that repair level decision. 
In NAVAIR this analysis can be economic, noneconomic or preempting factors such as 
safety or security. 

2. Model Overview 

- Model applies only to corrective maintenance. “Preventive maintenance 
requirement are developed through the Reliability-Centered Maintenance (RCM) 
process.” (NAVSEA, 1990) 

- Model purpose is to be done early in the development process “so that design can 
be influenced to allow for repairs to be performed at the lowest possible 
maintenance level.” (NAVSEA, 1990) 

- Model considers three levels of maintenance. They are organizational (O), 
intermediate (I), and depot (D). 

- LORA starts at the system level and then is conducted on the item level. 

- Final phase analysis is conducted to determine the actual level of repair. 
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3. Final Phase Analysis 

This is the last step in determining the optimum repair level. This phase consists 
five areas. They are item level screen, O-level evaluation, I-level evaluation, D-level 
evaluation, cost analysis, and analysis of LORA results. 

In item level screening, each item in the system is screened. ‘The screening process 
evaluates the item by assessing whether: (1) the item is a consumable, (2) the item has such 
a low cost that an analysis is not warranted, (3) pre-empting factors apply, and (4) 
remove/replace decisions pre-empt maintenance at certain levels.” (NAVSEA, 1990) This 
process ensures that only the items that warrant will receive a full evaluation. 

The O-level, I-level, and D-level evaluation are basically the same. The NAVSEA 
manual’s premise is “to drive repair authorization at the Reet level (O or I-level), provided 
that all the resources needed to perform the repair are available (existing and in-place) at that 
level, to maximize the achievement of readiness objectives and to minimize the supply 
support pipeline. If the Reet does not have the resources, cost analysis is performed to 
determine the lowest maintenance level that should repair the item.” (NAVSEA, 1990) 

The performance of cost analysis is of significant importance. If the capability for 
repair does not exist at any level, the cost analysis is performed to determine the least cost 
alternative. Basically the analyst sums all annual cost for the repair of an item and compares 
the cost from each level of maintenanee. There exists a degree of error based on the level of 
confidence associated with each variable. The analyst then selects the least cost alternative 
and determines the discard threshold. The discard threshold occurs when the unit repair 
cost is greater than the item cost. Then it is not economically effective to repair the item. 
After this step then analysis of the LORA results as a whole must be performed. This must 
be done because although one item’s repair level may have a minimal impact on supply 
support, the cumulative result of many items could have a significant impact on the supply 
and support needed. 
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III. DMSO AND THE NAVY 


In this section of the thesis we examine the Defense Modeling and Simulation 
Office (DMSO) and its interaction with the Navy. We research how DMSO came into being 
and its purpose. We also explore how the Navy’s modeling and simulation office evolved 
into its current place in the organization of the Navy. With computer modeling and 
simulation use increasing dramatically in logistics, it is important for a navy logistician to 
understand the organizational structure, relationships, and some history which may 
continue to influence policy and attitudes. 

A. THE DEFENSE MODELING AND SIMULATION OFFICE (DMSO) 

On June 21, 1991 the Defense Modeling and Simulation Office (DMSO) was 
established by the Undersecretary of Defense for Acquisition. DMSO’s purpose was to 
“serve as the executive secretariat for the Executive Council on Modeling and Simulation 
(EXCIMS) and to provide a full-time focal point for information concerning DoD modeling 
and simulation (M&S) activities.” DMSO is a joint staff that reports to the Director, 
Defense Research and Engineering (DDR&E), Office of the Undersecretary of Defense for 
Acquisition and Technology(USD(A&T)). (DMSO, 1995) 

DMSO’s purpose can be fully understood by reading of the foreward in the DoD 
M&S Master Plan. The foreward is 


The DoD Modeling and Simulation Master Plan is authorized by DoD 
Directive 5000.59, "DoD Modeling and Simulation (M&S) Management," 
January 4, 1994. The DoD M&S policies, organizational responsibilities, 
and management procedures are outlined in DoD Directive 5000.59. This 
Plan is the Department of Defense's first step in directing, organizing, and 
concentrating its M&S capabilities and efforts on resolving commonly 
shared problems. The immense breadth and scope of DoD M&S uses, 
combined with the relative immaturity of many segments of the larger DoD 
M&S community and its technology, ensure this first iteration is 
incomplete. Over time, with the active participation and support of die DoD 
M&S community, this plan will mature to address the full range of issues 
confronting DoD M&S. Many policy and technical issues may not be 
identified or resolved; however, this plan, with the management framework 
and policies established in DoD Directive 5000.59, provides a means to 
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achieve common technical and policy consensus. This plan is intended to be 
dynamic and flexible, a living document that will evolve as technology 
matures and consensus develops on policy and programmatic issues. 
(DMSO, 1995) 

DoD management of modeling and simulation is governed by DoD directive 
5000.59. This directive details the responsibilities of DMSO and EXCIMS and describes 
how DoD will manage modeling and simulation. It is interesting to note that the directive 
mandates, among many other things, that a DoD M&S Master Plan be developed and a 
coordinated DoD M&S investment plan be developed. The current version of the DoD 
M&S Master Plan is available and several functional area plans such as acquisition and 
DoD investment are still being developed two years after this directive was issued. 
Additionally, only master plans for the Army and the Marine Corps are present. In essence 
we are trying to manage modeling and simulation in DoD without having a complete plan 
from which to work. DMSO basically promulgates guidance and attempts to promote 
cooperation among all DoD components in order to increase efficiency in the use of 
modeling and simulation. 

In order to keep all services involved DMSO’s staff is a joint staff. It is comprised 
of officers from the United States Air Force (USAF), the United States Army (USA), the 
United States Navy (USN), and the United States Marine Corps (USMC). 

In 1991, DMSO started out with about $40 million. In 1992 the budget increased 
to $75 million. But, this year the pentagon cut the budget for DMSO to about $52 million. 
(Holzer, 1996) This is nearly full circle budgeting for this office. 

In its first year of existence DMSO began funding computer modeling and 
simulation. DMSO sent letters out to the individual services requesting proposals for 
consideration. DMSO funded 16 out of 230 proposals and funded zero at 100%. 
Additionally, the submitters of proposals were not given any feedback on the reasons of 
rejection. (McMasters, 1992) The lack of a strong, centralized, modeling and simulations 
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management structure throughout DoD and a constant budget crunch means an uncertain 
future also. 

B. NAVY INTERACTION WITH DMSO 

The Navy started out with an organization called Team Mike. Team Mike screened 
Navy proposals and forwarded them to DMSO for consideration. Team Mike started when 
the Director of ASW and Ocean Surveillance Programs was the Director of Naval Warfare. 
There were several teams representing functional areas in the Navy. These teams included 
Alpha-antisubmarine warfare, Charlie-C3, and Mike-modeling. Team Mike’s initial 
concern was finding support for wargaming, enhancing and setting up Reet Project Team 
for ENWGS at the War College and TACTRAGRU tool for Battle Group Commander and 
staff training. (Phillips, 1996) 

When the Director of ASW and Ocean Surveillance Programs became the Director 
of Naval Warfare and later the Deputy Chief of Naval Operations (DCNO) for Naval 
Warfare, the Director of Tactical Readiness Division reorganized under DCNO, Naval 
Warfare. The Heet Readiness Section worked for Director of Tactical Readiness Division. 
The Reet Readiness Section was involved in studies at the DoD level. (Phillips, 1996) 
DMSO then came into being with $70 million budget for the enhancement of modeling and 
simulation in DoD and a plan for pilot and demonstration projects. Team Mike became the 
vehicle for the Reet Readiness Section to promulgate opportunities to the Navy and screen 
navy requests for submission to DMSO. 

The Reet Readiness Section transitioned to the Navy Modeling and Simulation 
Section. As development of SECNAV Instruction 5200.38 began the question of “who 
owns Navy M&S” was addressed at the three and four star level. It was decided that 
Support to Operations should own it. (Phillips, 1996) The initial transition from DCNO, 
Resources, Warfare Requirements and Assessments to Support to Operations was delayed 
temporarily until the SECNAV instruction was signed. Additionally, the head of the 
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Assessment and Affordability Branch had departed in the spring and the billet was left 
vacant. Support to Operations decided to proceed with the transition anyway and the Navy 
Modeling and Simulation office was placed into Strategic Planning Office. The head was 
dual hatted as Assistant for Strategic Planning and Director, Navy Modeling and Simulation 
Management Office. The office’s focus was mostly on strategic planning so in mid¬ 
summer, “CAPT Jay Kistler was detached from SPAWAR and reported in as Director, 
Navy Modeling and Simulation Management Office. We were then extracted from the 
Strategic Planning Office nest and put on our own as the Navy Modeling and Simulation 
Office.” (Phillips, 1996) 

In 1994 SECNAV Instruction 52(X).38 was issued to give instruction on the 
management of modeling and simulation within the Department of the Navy. Team Mike 
was not included in the formal management of modeling and simulation within the 
Department of the Navy structure because it was determined that too many of the members 
were traveling too much in order to represent various outlying organizations such as 
NRAD, Port Hueneme, etc. Functional area managers were established and the use of 
appropriate representatives replaced Team Mike. 

Currently, the Director of Navy Modeling and Simulation is a Navy captain and the 
deputy is a USMC colonel. These positions rotate. The office establishes policy for Navy 
modeling and simulation and monitors the enactment of standards throughout the Navy. Its 
budget is for these purposes only. Funding and management for modeling and simulation 
comes from functional area managers. For example, DCNO for Training funds and 
manages training. However, the Marines have a quarterly modeling and simulation 
working group that represents a wide range of organizations across the Marine Corps. 
“Fleet representatives have indicated the need for working groups.” (Phillips, 1996) 

The Navy Modeling and Simulation Office attempts to keep abreast of all the 
activity between DMSO and the Navy. However, this is difficult due to the formal 


16 


structure that is in place. When the Director for Force Structure, Resources and Assessment 
set up a project office, the Joint Analytic Model Improvement Project, their point of contact 
is the Assistant DCNO for Resources, Warfare Requirements and Assessments. “Assistant 
DCNO for Resources, Warfare Requirements and Assessments office kept us informed of 
their actions.” (Phillips, 1996) Another example is the Joint Simulation Systems (JSIMS). 
JSIMS focuses on training and their point of contact is DCNO for Training. ‘The member 
of the JSIMS ‘General Officer Steering Group’ was designated as an assistant under the 
DCNO for Training.” (Phillips, 1996) The Navy Modeling and Simulation Office is not 
large enough to keep track of or participate in all Navy interactions with DMSO. The formal 
structure requires DMSO communicate with the Navy via the Secretary of the Navy 
(SECNAV) or the Chief of Naval Operations (CNO). “DMSO generally knows that to 
communicate with the Navy, they need to send us at least an info copy of the 
material....’’(Phillips, 1996) However, most information is gained through informal 
communication within the modeling and simulation community. 

Currently the Navy Modeling and Simulation Office is developing a Baseline 
Assessment Memorandum, an input into the POM development process, addressing the 
state of Navy modeling and simulation. “Likely output is that without a strong 
Heet/Lab/industry panel and voice. Navy M&S will be a back burner issue and will not 
thrive.” (Phillips, 1996) Working Groups get the ultimate customer in modeling and 
simulation purchases, the user, more involved and provides the management of the Navy 
with deckplate information on what is actually happening throughout the fleet. 

C. SHOULD THE NAVY CHANGE ITS MANAGEMENT OF M&S? 

To answer this question, the Navy should conduct its own internal examination. As 
to whether an internal examination should be conducted, we believe the Navy should look 
at what is happening in one of its sister services, the Army. “Critics of the manner in 
which the Army has invested in modeling and simulation say the service has lacked a 
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strategy, efficient management, and oversight.” The new Chief of Staff, Gen. Reimer, 
empowered an office in the Pentagon to focus the Army’s modeling and simulation. This 
office is the Simulation Strategic Planning Office (SSPO). 

The Simulation Strategic Planning Office (SSPO) is in charge of two teams that are 
“conducting a review of modeling and simulation projects, their funding and strategies, 
with and eye toward identifying efficiencies.” One of the duties of the teams is to define 
“what ‘models’ and ‘simulations’ are.” The teams are also “collecting a baseline of 
information about exactly what projects me taking place where; and determining the 
proponents for these projects.” (Sherman, 1995) 

The Army feels it is not getting a return on its modeling and simulation investment 
and is conducting an internal review and reorganization before it is ordered to do so. 
Aldiough SSPO is a new office, it has an opportunity to provide a tremendous impact to the 
future of modeling and simulation in the Army. ‘The new office is to develop and establish 
M&S standards, assess M&S management across the service, and provide centralized 
strategic management with a decentralized execution of the service M&S master plan.” 
(Sherman, 1995) 

We believe the answer to the question of change is possibly. The answer to the 
question of internal examination and assessment is definitely yes. The Navy should follow 
the Army’s lead and take a detailed look into where modeling and simulation dollars are 
being spent. 
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IV. KEY NAVY SIMULATIONS ISSUES 


A. OVERVIEW 

There are two problems with the use of computer models and simulations. The first 
is, how to properly use models and simulations in the many applicable areas to reduce cost, 
increase quality, and reduce time and risk in fielding new weapon systems. Second is how 
to buy models more efficiently and effectively by using modular design and reusing 
software. (Kistler, 1996) The proper solutions to these problems will dramatically increase 
the effective use of computer models and simulations within the Department of the Navy 
and the Department of Defense. 

Computer models and simulations do not determine missions. The mission comes 
first, then models and simulations. Matching computer models and simulations with 
missions is an important potential asset for decision makers. Well-designed computer 
models and simulations can help decision makers understand risks and uncertainties and 
thus have a more complete understanding of the problem they are facing. Determining the 
payoff of this use of modeling and simulation is next to impossible. This is because the 
determination of a utility function for the use of modeling and simulation is almost 
impossible. 

B. USE OF COMPUTER AIDED DESIGN (CAD) 

Probably the biggest ticket item in computer models and simulations right now is 
CAD, because CAD has the ability to influence every major acquisition DoD makes from 
now on. It is not without some problems however. In this section we will address the use 
of CAD in the new attack submarine and the surface combatant of the twenty-first century 
(SC-21). 

1. The New Attack Submarine 

The attack submarine program used intergraf CAD2. Electric Boat Corporation 
detailed Catia to develop a CAD like the one used for the Boeing 777. The problem from 
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the beginning was inoperability between various CAD systems and various shipyards with 
different CAD systems and non-transferable files. (Henry, 1996) Also, CAD is a huge 
initial investment for a program. Because of the CAD, there are more questions, so even 
more time is spent on feasibility studies. For example, there were about 80 feasibility 
studies for the Seawolf submarine. With the new attack submarine there have been over 
100 in-house feasibility studies and dozens more done by agencies outside NAVSEA 
already. 

Prior to Electric Boat getting the contract the Navy was using the Intergraf CAD 
system in the new attack submarine. Intergraf is a full blown geometric associative model 
that is designed to be run from a database using a network server. The Navy bought this to 
yield a product model. (Burkeen, 1996) Each ship must have its own product model (3-D 
physical model). Intergraf has 4 core products that are layered on top of one another. They 
are an engineering model system (EMS), an vehicle design system (VDS), a structural 
model (IS) and a systems model (IR). The systems model is piping, electrical, etc. The 
result is a non-integrated, complex system of software. 

There are two ways to design a software system. The first is top-down. This 
involves big picture software design. The second approach is bottom-up. This approach 
involves designing the little pieces which are uncoordinated and then integrating the entire 
system. Intergraf is a bottom-up approach. The advantage is practically all the software is 
commercial-off-the-shelf. The disadvantage is that the result was software that was bug- 
ridden and difficult to use. (Burkeen, 1996) Corruption on a model from a CAD and 
associative CAD system will propagate. This is because associative models are like graphic 
programs. An example would be machine parts. Different pieces of geometry have 
dependency or parents on which to build. Then functions similar to macros are run to yield 
the product. 
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The next version of CAD comes out and changes some commands and the result is 
implosion of the model. (Burkeen, 1996) In the early design phase this happened and the 
result was a fiasco. 

The use of CAD in detail became infeasible due to corruption. The corruption 
source was a combination of several factors. These include the modeler and the complexity 
of the system, lack of expertise, and the new version of the CAD. The utility of the CAD 
was questioned due to the short time frame of the benefit because the files were a non¬ 
retrieval format and therefore could not be reused. The end result was during early stage 
design the CAD became mearly an information system. 

One of the main preventers of progress in all computer aided engineering (CAE) 
being used effectively in design is no confidential network within the DoD agencies in 
Crystal City and Washington, D.C. People are performing the tasks manually, literally 
drawing on pieces of paper. CAD is more important as a communication device. DoD 
needs a functioning network and a product data manager. Additionally this network needs 
to be tied into the shipyards. This will be a very expensive investment. But, the current 
piecemeal fashion of operation leads to enormous waste. The waste is due to the system not 
being networked. The administrative cost and the cost of software to run stand-alone at 
NAVSEA is huge. The reason is the entire database must be duplicated at tremendous cost 
of time and money and risk corruption and then carried space-to-space. Currently the CAD 
is at Newport News and there is no way for NAVSEA to access it. The system needs to 
have everyone on a real network database and everyone plugged into it. There should not 
be isolated access areas like there are currently. (Burkeen, 1996) 

Another major area of concern is software development and management. For 
example, the technical point of contact cannot monitor actions because he cannot test or 
understand the source code. The reason is he gets a budget of $375,000 for software 
development. But, he cannot use one cent to buy hardware or software he needs because it 
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is forbidden by law. The current laws prevent him from using this money for the purchase 
of personal computers or operating systems because these items do not fall into the imder 
development category. “Engineers are buying software out of their own pocket to make life 
easier.” Laws and regulations governing expenditures of money do not match the new 
technological requirements and the procurement of software and hardware is not on pace 
with the technological development. Sanctions are preventing the procurement of 
inexpensive alternatives. (Burkeen, 1996) 

The management of the Federal acquisition process is highly regulated and 

IT procurements are subject to the following laws and regulations: 

-Brooks Act (P.L. 89-306) 

-Warner Amendment (P.L. 99-500) 

-Paperwork reduction Act (P.L. 96-511) 

-Paperwork reduction Reauthorization Act 
of 1986 (P.L. 99-500) 

-Competition in Contracting Act (P.L. 98-369) 

-Computer Security Act of 1987 (P.L. 100-235) 

-Privacy Act of 1^4 (P.L. 93-579) 

-Federal Acquisition Regulation (FAR) 

-Federal Information Resources Management 
Regulation (FIRMR) 

-Federal Property Management Regulation (FPMR) 

-OMB Circular A-130, Management of Federal 

Information Resources 

-OMB Circular A-76, Policies for Acquiring 

Commercial or Industrial Products and Services 

Needed by the Government 

-OMB Circular A-109, Major Systems Acquisitions 

-Plus any agency specific guidance regarding 

acquisition and operation of IT resources. (Willis, 1994) 

2. The Surface Combatant of the Twenty-first Century (SC-21) 

The SC-21 is also using the CAD in its program. In use is a Product Model 
Enhancement (PME). This graphic CAD system was developed by Intergraf in April 1990 
and used heavily in the LPD-17 program. Conceptual improvements were made in the 
system for use in the SC-21. The CAD is being used to place items on the ship in the 
design phase. 
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These items are graphically designed and placed into a data base. During the ship design 
phase about 20% of the items are modeled in the CAD file and about 80% are in 
specifications files or other non-graphic files. (Zebrowski, 1996) 

The PME control of the product database has been under development for about 
two years. This data base concept allows the entire ship and all the parts of the ship to be 
entered into the data base without graphics. As the design progresses the design can be 
updated. By mid-March this concept will be in full use for the SC-21. 

The CAD system that will be used involves three different software items. They are 
PME, Docmgr2, and metaphase. The system currently uses Orcle which is a relational 
software. However, the SC-21 program will be switching to Informix because they 
currently own the license to Informix along with CAD2. Docmgr2 is a commercial 
document management system produced by Intergraf. It is based on metaphase which is an 
object oriented management system. Now Orcle is a very robust system with a distributed 
data base that is designed to be networked. But, there is a logistics problem with security. 
The SC-21 program will probably get around the lack of secure network problem that is 
also present in the new attack submarine program. The SC-21 program plan is to 
piggyback on the modeling and simulation site in NAVSEA since this links to secure sites 
in other model and simulation centers. 

Currently Intergraf is comparing Informix and Orcle. This is to ensure that essential 
capabilities will not be lost when the program switches software. If the findings of the 
study indicate that some capabilities that are considered essential will be lost then the SC-21 
program will stay with Orcle. (Zebrowski, 1996) 

Potential problems with the use of CAD in the design and building of surface ships 
became evident in the DDG-51 program. There were two different shipyards with two 
different CAD systems. 
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With the use of CAD, there is a tendency to do some things on the ship first and then go 
back to the CAD and try to fix it. (Zebrowski, 1996) In order for CAD to work properly 
the discipline to use the model must be maintained. 

Currently, the CAD can only handle one ship vice a class of ships. In order to use 
the CAD for a second ship of the class, the data base must be created from the beginning. 
Phase 2 of the product model enhancer is being designed to handle classes of ships. It is 
also being designed to share the data amongst the ships of the class. This means to design 
the second ship of the class the data base will not have to be created from scratch. 

Does CAD yield a design faster? The answer to this question is both yes and no. 
For example, by hand maybe you could do 5 studies per week and now you can do 10 
studies per week. This improvement will hopefully allow you to get a better design out of 
the process. If you reduced the number of people because of computers, then your output 
will be the same as before computers. CAD still takes time but people ask for more things 
more often. There is the perception that if it is “done by computer, it’s instantaneous.” 
(Zebrowski, 1996) 

C. JSF (JOINT STRIKE FIGHTER) 

1. Background 

Joint Strike Fighter (JSF), previously known as Joint Advanced Strike Technology 
Program (JAST), is a joint program for the development of a new aircraft. JSFs vision is 
“A Joint Services Team creating the building blocks for affordable, successful development 
of the next generation strike weapon systems.” The service needs are as follows. For the 
U.S. Navy, a “first day of war, survivable strike fighter aircraft to complement the F/A- 
18E/F.” The U.S. Air Force needs a “multi-role aircraft (primary A/G) to replace the F- 
16.” Finally, the U.S. Marine Corps needs a “ASTOVL aircraft to replace the AV-8B and 
F/A-18.” The program is concentrating on developing a family of three aircraft. 
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The goal is to use a common production line to build the most affordable aircraft and to add 
service unique items to the aircraft. An example of a service unique item is the Navy’s 
aircraft carrier shipboard tailhook. (Hamman, 1995) 

2. Organization 

JSF is a highly successful joint acquisition program. Its success is directly 
attributable to its organization. The director of the program is U.S. Air Force and the 
deputy is U.S. Navy. These positions rotate according to normal personnel rotation plan. 
This arrangement ensures both principal parties best interest in the program is maintained 
and ensures teamwork. “The organization functions as integrated product teams.” 
(Hamman, 1995) 

3. Other JSF Issues 

The JSF program is using an extensive modeling and simulation process that 
includes virtual environment, prior to flight test. Although this modeling and simulation is 
on a much smaller scale than the entire Department of the Navy or the Department of 
Defense its success is due to its organization and management. One office manages and 
acts as a clearinghouse for all simulations with the program. The money flow is directly 
traceable from the director down and the exaet amount of dollars being spent on computer 
modeling and simulations is known. 

In the area of simulations, there does not appear to be a strong simulations 
applications program in place. There is an area in the “Modeling Simulation & Analysis 
Process” for JSF that is called “constructive simulation”. However, when examining this 
area in detail it looks as if this is the use of different models to evaluate campaign, mission, 
etc. and not a graphical simulation program. There are several areas in which a graphical 
simulation would be beneficial to the decision makers. One of these would be a simulation 
of the “common production line.” (Hamman 1995) 
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We did note, with some interest that while JSF is a joint program, the analysis of 
the Services logistic data is being kept separate. “So analysis on USAF comparative data 
would use NRLA and USN data would use LORA. We have not reached the point where 
production or production-like designs are being looked at in detail by government 
analysts.” (Hamman, 1996) NAVAIR has taken the lead in developing the Joint Aviation 
Model (JAM) for use in the JSF program. JAM will be discussed in detail in Chapter V of 
this thesis. 

D. CONTINUOUS ACQUISITION AND LIFECYCLE SUPPORT (CALS) 

“ Continuous Acquisition and Lifecycle Support (CALS, also known as Commerce 
At Light Speed) is a strategy to accelerate the transition from paper-intensive non-integrated 
product development design and manufacturing, and support processes to a highly 
automated, integrated mode of operation by developing (1) standards for data storage and 
exchange; and (2) automated systems to store, manage, and distribute this information to 
many and varied users across an enterprise.” (CALS, 1996) CALS was originally 
developed in 1984 and was known as Computer-Aided Logistic Support. The Deputy 
Secretary of Defense issued two memorandums “to establish plans to acquire, process, and 
use technical information in digital form.” (CALS, 1996) In 1987, the name was changed 
to Computer-Aided Acquisition and Logistic Support. “This brought in functions and 
disciplines associated with contracting, work breakdown structures, design specifications, 
drawing preparation and release, testability, produce-ability, reliability and maintainability.” 
(CALS, 1996) Later, CALS name was change to its current form and more government 
agencies became involved. CALS is now starting to attract European and Pacific Rim 
countries. 

Why did CALS start? The answer to this question is money. DoD managed many 
of its weapons systems and acquisitions manually and on paper. “DoD spends more than 
$10 billion annually to store, maintain, and revise the technical data needed to support 
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weapon systems.” For example, “the technical manuals needed to perform maintenance and 
repair on a Navy destroyer weigh 23.5 tons. Overall, the Navy maintains more than 237 
million drawings and more than 15 million technical manuals, at an annual cost of over $4 
billion.” The other branches over service spend similar amounts of money on these same 
types of items. (CALS, 1996) 

“The objectives of CALS are to improve timeliness, reduce cost and improve the 

quality of products and their supporting technical data.” The accomplishment of these 

objectives is essential for the military and the government in this era of declining budgets. 

The immediate goal of CALS is to provide basic capabilities for the digital 
transfer of engineering drawings, technical and training manuals and logistic 
support products. The longer term goal is the development of integrated 
databases that represent all current technical data about a product through 
each stage of its life cycle. It is through this long term goal of shared 
databases that integrated product development (concurrent engineering) and 
other parallel acquisition processes can take place. (CALS, 1996) 

CALS will achieve these objectives by using standards. “CALS incorporates three 

types of standards.” They are functional, technical interchange, and data standards. 

Functional standards refer to “ data creation and the content and format of data products.” 

Technical interchange standards are standards “which control the medium and process of 

exchanging data between sending and receiving systems.” Data standards “govern 

information sharing and data exchange in an open system environment. CALS philosophy 

is that to function competitively, management must realize that national and international 

standards are the conduits for carrying U.S. Products, services, and technologies into the 

global marketplace. (CALS, 1996) 

In order for CALS to accomplish the aforementioned goals and objectives STEP 
must be developed and implemented. “STEP is being designed to give a complete, 
unambiguous, computer interpretable representation of a product throughout its lifecycle.” 
This is a progression from sharing data to multiple user interface. In this system many 
users, organizations, producers and consumers will be able to access life cycle data on a 
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product. “Data access delivery and distribution will be through Contractor Integrated 
Technical Information Services (CITIS). CITIS is the vehicle to provide consumers with 
access to information associated with life cycle product development.” This information 
system will control access to data and ensure that users can access only what they are 
authorized to access. (CALS, 1996) 

As previously stated, a long term goal of CALS is integrated product development 

or concurrent engineering. STEP is the essential element to achieving this goal. 

Concurrent Engineering is the systematic approach to creating a product 
considering all lifecycle elements and in doing so, simultaneously defining 
the product, manufacturing process, and support. Concurrent Engineering 
applied to manufacturing is a critical link in the enterprise and life cycle of 
any product. CALS is the integration of information whereas Concurrent 
Engineering is the integration of processes. This combination is necessary 
to achieve the ultimate goal of Enterprise Integration. (CALS, 1996) 

CALS has become a key logistics ingredient in several Navy programs. One of 

these programs is the Seawolf attack submarine program . Newport News Shipbuilding is 

the lead design yard for the Seawolf. “To stay competitive, CALS principles and concepts 

are imbedded in designing and building major weapon systems. This fact has been most 

apparent in the design of the Seawolf, the first submarine totally designed using 

computers.” The development and implementation of STEP will be the last item needed to 

make CALS complete. “The technology and standards for exchanging a fully attributed, 

three-dimensional solid model are not yet available-for that we must have STEP.” (Burke, 

1992) In the meantime, CALS principles and concepts are being used and probably will 

remain in place for long into the future. 
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V. JOINT SIMULATIONS 
A. JAM (JOINT AVIATION MODEL) FOR LORA 

In this section of the thesis, we take a brief overview of JAM. JAM was developed 
because there did not exist a tool to provide a Joint NA VAIR/Air Force acquisition program 
repair/discard decisions. “JAM is being produced to provide a single (software application) 
level of repair analysis model to accommodate the Navy, the Air Force, and Joint program 
needs. A Memorandum of Understanding between NAVAIR and Air Force (Jan 93) agreed 
to pursue this joint project. The Air Force provided $150K from the V-22 program and 
NAVAIR provided $37K (and agreed to provide additional funding as required.)” 
(Hamman, 1996) The information contained in this section was obtained from the paper 
“The Genesis of JAM for LORA” by Stephen H. Doragh. 

1. Background 

The idea for a joint Level of Repair Analysis (LORA) program initially began at the 
V-22 “Osprey” program office at Naval Air Systems Command (NAVAIRSYSCOM) in 
1993. “Joint acquisition programs area those that involve more than one service (Army, 
Navy, Marine Corps, United States Air Force (USAF), and occasionally. Coast Guard, & 
Federal Aviation Administration (FAA)) in the development and acquisition of a weapons 
system by the government. In the case of the V-22, all three military services were involved 
when the acquisition program began.’’(Doragh, 1995) Joint programs present a whole new 
set of problems for the program. Each service has its own LORA models for its own 
acquisitions. Each LORA model is biased toward the maintenance philosophy and policies 
of the individual service. “For example, NAVAIR’s model provides for aircraft to be 
stationed on aircraft carriers, the Army’s model has five repair levels, and the USAF’s 
model is designed to be run by end item. However, in light of the smaller defense budgets 
projected for the future, it is assured that ‘joint’ programs will become more and more 
common.” (Doragh, 1995) 
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The peculiarities of each services’ models create a quandary 
for the program office of a ‘joint’ program. Do they use one 
service’s LORA model for dl repair level studies and accept 
that the selected model will not precisely fit all of the 
services’ maintenance scenarios? Or do they allow each 
service to use their own model for the end items they will 
operate, e.g., “Enter the Navy’s aircraft in a navy model and 
enter the USAF’s aircraft in the Air Force’s model?” The 
problem with the latter approach is that any advantages 
gained by having combined LORA runs and optimizing the 
support equipment use for all Intermediate Maintenance 
Activity (IMA) sites and depots are lost. (Doragh, 1995) 

This led the Osprey program office to begin pursuing a joint LORA model. “They 

realized: (1) that NAVAIR and USAF have very similar maintenance philosophies for 

corrective repair of aircraft and its equipment; (2) that one LORA model could be developed 

for use by both services; (3) that each service also had its own, aging LORA model that 

required updating; and (4) both models used old software techniques that did not take 

advantage of the capabilities of modem personal computers.’’(Doragh, 1995) The result of 

this pursuit is JAM for LORA. 

2. LORA/NRLA Similarities 

- “Both models calculate the total operating hours of all operating end items at all 
operating sites to determine the total number of failures for the items under 
analysis.” 

- “The USAF s maintenance planning policy has a greater bias towards two level 
maintenance (Organizational Level to the Depot) than the Navy’s policy. However, 
both models require the user to enter data as if the items under analysis were going 
to be repaired using a three level maintenance concept (Organization to Intermediate 
to Depot). The models then test both the two level concept and the three level 
concept to determine the maintenance plan with the lowest cost for maintenance 
over the life cycle of the system being studied.” (Doragh, 1995) 
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- “Both models determine the cost “impact” of a maintenance concept on existing 
maintenance sites. The models assume that the sites already exist with hangars, 
runways, common support equipment, and a standard manpower complement. 
They measure what the costs of adding the items under analysis to these sites will 
be in various combinations and compare them to each other.” 

- Both models lack a on-line help feature. 

- Both models were designed for use in a non-Windows environment. 

- Both models were designed and produced before LSAR Mil-Std’s-1388.2A or 
1388.2B were developed so they cannot take full advantage of the LSAR database. 

- Both models were written in older computer languages (NRLA- FORTRAN; 
LORA- C-I-). 

- Like all software programs, both models require updating or improvement but 
neither had a steady funding source for this purpose. 

- “Both models assign the “costs of support equipment” to the LORA candidates 

that use the support equipment before the optimization is begun.” The way the 

models assign the costs vary slightly. However, this is a problem for both models. 

The fundamental problem with these methods of optimizing 
LORA data is, the models are attempting to determine the 
support equipment cost for each item at each site before the 
repair level has been determined. When using these 
methods, the model cannot always know how many items 
are going to be repaired at a site and cannot determine how 
many hours per month a piece of support equipment is used. 

So, the model cannot always know how many pieces of 
support equipment need to be purchased for each site or how 
to allocate the costs of the support equipment to the items at 
each site. (Doragh, 1995) 

3. JAM Algorithm 

In setting up JAM for LORA, the team realized the flaws in LORA and NRLA. 
They realized that those optimization models “did not, and could not, always return the best 
solution for all items and support equipment.” (Doragh, 1995) There are basically two 
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options for the optimization routine. “What we discovered was that we had two choices: (1) 

perform an analysis on every possible alternative, called an ‘exhaustive’ search; or (2) use a 

new optimization routine that mimic Charles Darwin’s theory of evolution or ‘natural 

selection’ called ‘Genetic algorithms.’” (Doragh, 1995) 

An exhaustive search was determined to unfeasible. The total number of possible 

maintenance plans was found to be equal to the number of repair levels raised to the power 

of the number of items under consideration. Each service defined what they considered a 

valid maintenance plan. This total number includes plans that would be considered invalid. 

The two constraints that any valid maintenance plan must 
adhere to are: (1) A lower indenture level assembly must be 
repaired at the same site level or higher site level as its next 
higher indenture level assembly. When running LORA’s the 
lowest site level is the ‘squadron’ or ‘organizational’ level, 
the next highest site level is the ‘depot’ (commercial or 
organic), and the highest repair decision is ‘discard’. (2) All 
lower indenture level assemblies of a discarded candidate are 
discarded with that item; that is, no analysis is performed for 
those lower indenture level discarded items. (Doragh, 1995) 

The reason that the exhaustive method was abandoned was the computation time. For 

example, “suppose an input file has three levels (IMA, depot, & discard) and 15 items, the 

total number of alternatives is 14,348,907.” If you eliminated half of the alternatives due to 

violation of the valid maintenance plan constraints, and assumed only 30 seconds to 

complete the computations for each iteration of the model, “it would take about 60,000 

hours (or 2491 days or 6.8 years) to finish all of these runs and find the optimal solution.” 

(Doragh, 1995) 

Thus the “Genetic Algorithm” (GA) was selected as the best alternative to pursue. 
The algorithm basically uses the rules of nature to find the best solution. It searches a “state 
space” where all possible solutions are located. Then the algorithm combines “parts of the 
most successful solutions, to create more successful solutions using a process called 
‘mating’”. (Doragh, 1995) The cost module is separate in JAM. The GA creates 
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maintenance alternatives to be evaluated by the cost module. ‘The cost of the alternative is 
returned to the genetic algorithm and then the genetic algorithm determines the relative 
quality of the answer.” (Doragh, 1995) It avoids the support equipment problem 
experienced by the other models by giving the repair level for every item to the cost module 
by the GA. “JAM for LORA is ‘given’ and then calculates exactly which pieces of support 
equipment are required for every site and how many of each support equipment are 
required for each site, for every iteration of the Cost Module.” (Doragh, 1995) 

4. JAM Characteristics 

- It can be used for joint Navy/USAF programs. Navy only programs, or USAF 
only programs. 

- It operates in the Windows environment. 

- It is user friendly. 

- It has on-line help. 

- It continuously updates its database as the user enters data. 

- It is written in a database computer language (Foxpro). 

- It “calculates the total number of operating hours per month at each site for each 
aircraft type (or end item).” (Doragh, 1995) This allows the user to compute “site 
operating hours.” 

- It can show an “Item Efficiency Index”. “This is an output report that shows the 
relative impact of changing inputs that affect an item’s ‘availability’ ”. 

(Doragh, 1995) 

- It can run separate “systems” in the same model run. 

5. JAM Reports 

JAM for LORA has the ability to generate the following reports: 

- Item repair dispositions 

- Item disposition (detail/summary) 
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- Life cycle cost (detail/summary/summary by site) 

- Support equipment 

- Inventory (detail/summary) 

- Optimization graph/list 

- Standard summary 

- Top ten summary 

- Sensitivity analysis (Doragh, 1995) 

6. Engine LORA Model (ELM) 

Also under development is ELM. This model is very similar to JAM except it is 
tailored for gas turbine engines. It will also have the ability to be used for Navy only, 
USAF only, or joint USAF/Navy engine programs. 

B. JOINT MATH MODELS 

In this section, we will discus briefly several joint math models being developed at 
the Joint Logistics Systems Center (JLSC). The purpose of these projects is to look at 
standardizing models used for setting wholesale and retail inventory levels. It is the 
intention of this section to give a logistician some insight into the tools currently being 
developed. 

1. Statistical Demand Forecasting (SDF) 

This model’s purpose is to forecast the mean and variance of the net demand during 
the procurement leadtime and the demand during the repair tum-around-time for use in 
requirements determination. “This model forecasts the means and variances (where 
appropriate) for the following variables: demand, regeneration, final recovery rate, 
unserviceable returns, unserviceable return rates, serviceable return rates, nonrecurring 
demand rates, administrative leadtime, production leadtime, procurement leadtime, 
retrograde time, administrative repair time, depot maintenance time, and depot repair cycle 
time.” When using the model, different forecasting items are available for different items. 
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The model can be applied to consumable and repairable items, program and nonprogram 
related items, and family and bachelor items. 

‘The model uses Statistical Process Control (SPC) techniques to identify when a 
change in the demand pattern is statistically significant and requires an update (or change) 
to the forecast.” It can also provide for the identification, exclusion, or modification prior to 
use, of outlier observations. The model has the ability to identify trends and adjust the 
forecast accordingly. “The SDF consists of two parts: a ‘black box’ subroutine accessed by 
Requirements Control System (RCS) and Central Secondary Item Strati-fication (CSIS); 
and, a PC Exception Tool, used to review/change/simulate/re-forecast items.” (Moore, 
1996) 

2. Economic Order QuantityA^ariable Safety Level (EOQA^SL) 

The EOQ/VSL math model is used for computing inventory levels for secondary 
items. This model does the mathematical calculations and processes required for this 
computation. “The model acts as a ‘black box’ accessed, as required, by DoD systems, 
including the Requirements Computation System (RCS), Simulation Recomputation Tool 
(SRT), Central Secondary Item Stratification (CSIS), and Computation and Research 
Evaluation System/Supply Performance Analyzer (CARES/SPA).” In the model 
consideration can be given to both family and nonfamily items. 

The system basically provides output based on whatever input it is given. “The 
accessing system provides the input and parameter data and the model returns the output 
data to the accessing system.” The model performs all necessary mathematical 
computations to determine when and how much material to buy and repair, “as required by 
RCS, SRT, CSIS, and CARES/SPA.” The model will compute order and repair quantities 
and reorder and repair levels. It can compute for consumable, repairable, family and 
nonfamily items. “Necessary preliminary calculations (initial values and constraints and 
special case establishment and follow-on calculations (backorder, final quantities. 
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performance projections, and family prorating) are also performed by this model.” (Moore, 
19%) 

3. Computational And Research Evaluation System/Supply 

Performance Analyzer (CARES/SPA) 

CARES/SPA provides the information necessary to set parameters used in the RCS 
and CSIS. It is a stand alone point-in-time simulation system. “ CARES/SPA provides and 
experimental tool to evaluate proposed inventory methods and models and to determine 
shortage cost values.” The EOQ/VSL “black box is the common model used in the 
CARES/SPA, RCS, CSIS, and the Simulation Recomputation Tool (SRT).” 

The CARES/SPA model may be used on a sample grouping (e.g., “universe of 
items with similar characteristics) using one of the four different target types. The types are 
fill rate, dollar value safety level, average wait, and a chosen lambda value. When using the 
first three types, the model searches for a lambda that will achieve the specified target level. 
“The fourth option evaluates certain lambda values to determine the impact on measures 
such as fill rate, average wait, inventory investment, and cost and number of first year 
buys.” CARES/SPA has a Multi-Link capability. The user of the program can select a 
target either by National Stock Number (NSN) or NSN group. “For certain user-specified 
items, Multi-Link provides a multi-echelon computation to determine Ihe performance target 
that the wholesale echelon should provide.” It should be noted that all outputs provided by 
CARES/SPA for non Multi-Link items are also provided for Multi-Link items. (Moore, 
19%) 

4. Readiness-Based Sparing (RBS) 

In the world of computer models, new models are being developed constantly for 
application. At JLSC, another joint model being developed is RBS. Although very few 
details are available on RBS, it serves as an example on the constant growth in the field of 
math models. JLSC is developing “retail readiness-based sparing (RBS) models which are 
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used to determine secondary item requirements for retail (user) sites in a manner which 

provide the most readiness per dollar of inventory investment.’’(Moore, 1996) 

C. JOINT SIMULATION SYSTEMS (JSIMS) 

In this section we will look at another Joint simulation. While not directly a logistic 

model or simulation, it provides some insight into potential problems that are faced when 

conducting a Joint program. Even though the future of simulations and models is joint, 

they are under constant scrutiny and must be managed carefully. 

“The General Accounting Office (GAO) says the Defense Department’s effort to 

develop a Joint Simulation System is well behind schedule and still lacking a consistent 

focus, which auditors say could allow DoD to pursue unnecessary upgrades to the current 

system and let services develop programs that may duplicate the capabilities of JSIMS.” 

(Dupont, 1995) The GAO is under the opinion that “the JSIMS program ‘hcis not 

progressed beyond the conceptual stage since a memorandum of agreement was signed in 

June 1994.’” (Dupont, 1995) It was intended for JSIMS to replace the Army’s current 

Aggregate Simulation Protocol (ALSP), which is currently managed by the Army’s 

Simulation, Training and Instrumentation Command. (Dupont, 1995) 

The Joint Staff and the individual services are in disagreement “about the definition 

of JSIMS and a plan of action”(Dupont, 1995). Meanwhile the Undersecretary of Defense 

for Acquisition and Technology has chosen not to get involved but rather to let the 

differences be solved over time. 

‘Further’, the report continues, ‘the estimated $416 million 
in funding needed to develop JSIMS will be dependent upon 
agreement by multiple sources- the service and other 
agencies.’ In addition, DOD is ‘uncertain’ how much it will 
spend to improve ALSP confederation before JSIMS is 
available. ‘This uncertainty raises questions as to whether 
DoD is making cost-effective decisions.’ (Dupont, 1995) 

In the GAO report, $40 million was determined to planning for improving ALSP 

through fiscal year 1999. It is estimated that many of the improvements to ALSP will be 
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finished at approximately the same time that it is scheduled to be replaced by JSIMS. ‘“The 
longer it takes to make JSIMS operational, the more money DoD is likely to spend on a 
system that will be ultimately discarded.’ In the meantime, GAO states,'the services are 
already developing their next generation of training models without a clear vision of their 
relationship to JSIMS,’ which could lead to duplicate costs and capabilities.” (Dupont, 
1995) DoD only partially concurred with this GAO report. 

D. GENERAL-PURPOSE SIMULATION LANGUAGES 

Simulation languages have increased in popularity. The use of simulation languages 
is necessary for process analysis improvement. There are several simulation languages 
available. These include Simscript, Modsim, GPSS, and Arena. We have chosen Arena as 
an example of a simulation language. 

It is evident that the Navy has many specialized, high level models and programs in 
place. Each of these models and programs provide valuable information for logisticians. 
However, there exists a necessity for process simulation using animation. Process 
simulation using animation adds a key element to effective logistics planning and 
management. That element is communication. 

DoD no longer has the luxury of large budgets. We cannot afford to spend money 
on something unless we are reasonably sure of its potential success. Simulation using 
animation is necessary for “reengineering” the way we do business. It provides a medium 
for engineers and analysts to effectively communicate plans and proposals to the decision 
makers. The animation portion allows these decision makers to actually view the impact of 
a logistics proposal. For example, the decision maker could see the queue growing at an 
intermediate maintenance facility without having to read through reams and reams of 
numerical and statistical data output 

One of the most flexible, powerful, and easy-to-use simulation animation programs 
is Arena developed by Systems Modeling Corporation. Arena can be applied to any 
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logistics situation and is very effective in representing through animation the process being 
simulated. Prior to releasing Windows 95, Microsoft used Arena to “determine the effect 
of the higher volume of customer support calls.” The result was customers waiting less 
than two minutes to receive assistance. (Ferguson, 1996) 

Arena is “a comprehensive system that addresses all phases of a simulation project 
from input data analysis to the analysis of simulation output data.” Systems Modeling 
Corporation designed Arena to build on the capabilities of Siman and Cinema, two of their 
earlier products. Arena allows a user to easily and quickly model and simulate using 
animation. This is due to the fact that Arena uses drag-and-drop and windows that allow 
the user to fill in the blank. However, “a professional user can actually build his or her own 
simulation system by combining Siman and Arena constructs into modules for the end- 
user.” (Hammann, 1995) 

Some of Arena’s applications are manufacturing, logistics, transportation, 
warehousing, and process. (Ferguson, 1996) However, Arena can be tailored to any 
specific application area. Arena could be tailored to any logistics area. It could be tailored 
to simulate a ship refueling, supply offload, or an aviation maintenance plan, just to name a 
few. 

As stated earlier. Arena could be tailored to fit any area of logistics. In this thesis 
we have examined several weapons programs that are ongoing. Arena is a powerful 
communication tool that could yield immediate results to the program managers. Arena’s 
ability to simulate using animation would allow these program managers to better 
communicate the logistical details of their program to the decision makers in the Navy and 
DoD. 

One example of the use of Arena would be in the JSF program. Arena could be 
used to simulate, using animation, the operation of the common production line. This 
would allow the decision makers to view the planned flow of parts and equipment on the 
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line. The workload of each planned station of the production line could be viewed. Arena 
would also allow the decision makers to view the output of the three aircraft (USMC, 
USAF, USN) of the family of aircraft. The animation would communicate this production 
line plan more effectively than any other means available. 

Additionally, Arena would allow the incorporation of the level-of-repair analysis 
programs findings into an animation of the repair plan for the JSF. Arena could model the 
repair plan recommended by NRLA, LORA, and JAM. A visual representation of the 
maintenance plan is valuable for both the logistician and the decision maker. By being able 
to see the projected maintenance workload, the logistician for the program could quickly 
identify potential problem areas before the maintenance plan is adopted. Arena would also 
enable the decision maker to witness the plan “in operation” well before the maintenance 
plan is adopted and implemented. This will ultimately save time, money and increase the 
quality of logistic support for the program. 


VI. SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS 

A. SUMMARY 

As Defense budgets continue to decline, computer modeling and simulation use will 
rise. Computer modeling and simulation is a cost effective way to conduct analysis and 
influence program designs toward the most effective and economical design from a logistic 
perspective. While this thesis provides a Navy logistician with some insight into modeling 
and simulations, there are changes occurring everyday. Technology continues to advance at 
a rapid pace and improvement in pc technology allow a logistician to perform analysis on 
his personal PC that would have previously required mainframe computers. It is important 
for the Navy logistician to stay informed about modeling and simulation developments 
especially with the move towards off-the-shelf technology uses. It is especially important 
for the Navy logistician to get involved early in the development of a system or program 
and use computer modeling and simulation assets to influence design from the very 
beginning. This will result in not only the most economical system design but also the most 
supportable design over the long term. 

B. CONCLUSIONS 

-There are many specialized computer models and programs in DoN but there exists 
a necessity for process simulation using animation. 

In DoN, we do not take advantage of process simulation. We have many specialized 
computer models and programs, some of which have been discussed in this thesis. These 
include LORA, JAM, and ELM. While these programs provide excellent information, they 
are not process simulations. Process simulations will provide an excellent communication 
and evaluation and analysis tool for a logistician. 

- The ultimate user of computer modeling and simulations is not being involved in 
the acquisition decisions resulting in purchases being made of incorrect hardware 
or software. 
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The Department of Defense has a golden opportunity to set up a simplified management 
structure right now. The FT96 DoD Authorization Act has removed some cumbersome 
legislation in the area of information technology. The main highlight is the repeal of the 
Brook’s Act. However, if we in DoD do not show Congress that we can manage ourselves 
in this arena, legislation similar and possibly more restrictive than the Brook’s Act will be 
put in place. User involvement in the process of ADP acquisition is missing. Also, users 
are not educated in the process and their is a “user and buyer disconnect”. (Stone, 1996) 

-The Navy modeling and simulation office is unable to effectively mange computer 
modeling and simulation within the Department of the Navy due to the 
organizational structure of computer modeling and simulation management in the 
Department of the Navy. 

Computer modeling and simulation is being used widely in the Department of Defense and 
the Department of the Navy. However, determining the payoff is very difficult because of 
the bureaucratic management structure. We must learn to manage computer modeling and 
simulation more effectively if it is going to pay the dividends we need it to in the future. 

- Simulations and models must lean toward the ability to perform joint functions. 
More acquisition programs are joint programs due to the decreasing defense budgets. With 
decreasing budgets, money is not available to update, correct, and maintain numerous 
computer models. 

C. RECOMMENDATIONS 
We recommend that: 

-DoN promote the use of process simulation using animation (eg.. Arena) for all 
logistics programs. 

While the models and simulations we currently have provide essential information, they are 
also very specialized. The information then must be provided to the decision maker for the 
program. Process simulation using animation provides an excellent tool for communicating 
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a logistics plan to the decision maker. Communication is the key. Animation provides a 
concise way to communicate a logistics plan and also allows for sensitivity analysis. The 
ease of use of process simulations such as Arena is an additional plus. 

-Reorganize the management structure of computer modeling and simulations. 
Move the Navy Modeling and Simulation Office to the Secretary of the Navy level, 
specifically the Assistant Secretary of the Navy for Research, Development and Acquisition 
Office, in order to provide more influence, visibility, and say in budgetary matters. Direct 
that the Navy modeling and simulation office define what will be considered and “model” 
and what will be considered a “simulation”. Additionally, DoN direct that the Navy 
Modeling and Simulation Office control the funding for computer modeling and simulations 
within DoN and all functional area managers will report to the office on modeling and 
simulation matters and receive their funding for modeling and simulation from the office. 

-The Navy Modeling and Simulation Office reestablish Team Mike, using video 
teleconferencing if necessary to reduce travel expenses. 

This will get the users involved in the process and educate them. Additionally, this will 
ensure that the leaders and managers of Navy modeling and simulation are hearing 
unfiltered feedback from the users in the fleet. 

-DoN conduct a thorough study of the current ADP acquisition laws and regulations 
and influence the simplification and elimination of them where necessary to keep up 
with the fast-paced changes in technology. 

In some cases, rules and regulations prevent the purchase of necessary computer hardware 
or software. In other cases, theses same rules and regulations result in the purchase of 
more expensive hardware or software because purchase of the less expensive items is 
disallowed. Many of these wastes of money could be eliminated through the use of 
common sense. Rules and regulations that no longer make sense or have outlived their 
usefulness given the fast pace of technology should be eliminated. 
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-Ensure budgeting for computer modeling and simulation within DoN is 
incorporated within the POM. 

If modeling and simulation is to be a high priority for the Navy, it must be in the POM. 
There is a lot of truth to the belief that if you are not in the POM, you do not exist. Money 
needs to be available for correcting, updating, modifying, and maintaining our computer 
models and simulations to ensure we are receiving the best product for our taxpayer dollar. 



APPENDIX. POINTS OF CONTACT 


This appendix contains a list of the main points of contact used in this thesis. Their 

names, phone numbers, and electronic mail address is listed if available. The information 

contained herein is intended to assist others interested in conducting follow-on research. 

1. DMSO: Steve Stamer, phone: 703-824-3429, 
email:sstamer@msis.dmso.mil 

2. Office of the Secretary of Defense: Capt. Bury (USN), phone: (com) 703-695- 
4813, (a/v) 225-4813, fax: 703-614-3424, email: BurySJ@acq.osd.mil 

3. Navy M&S Office: Capt. Jay Kistler (USN), phone: 703-695-8206 

4. SPA WAR: Mr. George Phillips: phone: 703-69S8206, email: phillipg@smtp- 
gw. spawar. navy.mil 

5. CAD; preliminary submarine design: Mr. Mark Henry, phone: 703-602-5083 
Mr. Frank Burkeen, phone: 703-^2-5607, email: 
Burkeen_Samuel@hq.navsea.navy.mil 

6. CAD; SC-21: Mr. Rick Zebrowski, phone: 703-602-2151 ext. 207, email: 
zebrowski_rick@hq. navsea. navy, mil 

7. JSF: LCDR Tom Hamman, phone: 703-602-7390 ext. 6632, email: 
hammantr@ntrprs.jast mil 

8. JAM: NAS PAX River, Mr. Randy Barthlett, phone: (com) 301-342-4262 (a/v) 
342-4262 

9. JLSC: Mr. Rich Moore, phone: (com) 513-255-3320 (a/v) 785-3320, email: 
rchmoore@jlsc.wpafb.af.mil 

10. LORA (USN): NAVSEALOGCEN, Mr. Russ Jenkins, phone: 717-790-4509, 
email: russel_dJenkins@nslc.fmso.navy.mil 

11. COMPASS (USA): LOGSA, Army LORA Support Office, 

Mr. Christopher Booth, phone: (a/v) 645-9838, email: 
cbooth@logsaemh2.army.mil 

12. NRLA (USAF): Mr. Rich Lamb, phone: 513-255-2122 ext. 580 
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